---
alias: canonical meta, Canonical meta, canonical Meta
gardenid: M1
---
# [[Production]]
## [[Scratchpad]]

*The content below is a draft.*

---

# Canonical Meta
## What is a Meta?
**Meta** is how I call:

- The way a [[personal knowledge base]] I've made works.
	- i.e. its *data model*, and all the workflows that help maintaining its data.
- A description made for myself (and others) of how a personal knowledge base I've made works.
	- i.e. the documentation of its *data model* and all the workflows that help maintaning its data.

In short: it's my own nickname for something quite banal. But doing it makes my [[digital garden]]s comfier for myself.

## Principles of a Meta
- **Translatability**
	- Metas must strive to be easily translatable.
		- A well-defined Meta is easier to translate.
- **Modularity**
	- Each Meta must be able to develop its own solutions for its own particular problems.
- **Formalization*
	- Metas must be both *readable* and *amenable to formalization*.
		- No compromises: maximal readability must co-exist alongside maximal formalization.
- **Flexibility**
	- Metas must strive to be flexible both synchronycally and diachronycally.
		- Multiple structures must coexist inside a Meta.
			- Metas must have both vertical and horizontal structures.
				- No compromises: maximal verticality must co-exist alongside maximal horizontality.
		- Metas must be able to change throughout time without imploding.
			- Metas must be able to productively die and lend themselves and their data to be consumed by other Metas, if necessary.
- **Forgiveness**
	- No Meta can promise itself, let alone others, to perfectly follow its own principles.
## What is a canonical Meta?
There are advantages to having multiple personal knowledge bases, public or private. However, one particular and nasty disadvantage is not having the same data model and/or a way to translate different models. This is why some [[Zettelkastener]]s defend [maintaining a single, unified knowledge base for your entire life](https://zettelkasten.de/posts/how-many-zettelkasten/).

Nonetheless, I've found a way to avoid this problem for myself by making a default data model upon which all my personal knowledge bases build themselves, and which they translate back to. That's what I call my **canonical Meta**.

## The structure of a Meta
### Garden
A **garden** is a small world embedded into a digital or analog medium. It contains **inhabitants**.

### Inhabitants
A garden's **inhabitants** can be:

- **Gardeners**, conscious and non-conscious subjects of any kind who build a garden.
	- i.e. people, tools used for building a garden, AI, and possibly a few alien species.
- **Environment**, the data that exists inside a garden.
- **Handbooks**, the consensus between gardeners on how to structure an environment.
- **Neighbors**, everything that exists outside of a garden.
	- i.e. the entire Universe, *sans* my gardens.

From the point of view of a garden, everything that inhabits it is an entity composed of data.

### Environment
An **environment** is a structure which can only see and work with *itself*. It is the job of gardeners to translate neighbors into its data model. An environment has its own life, producing data of its own

An environment is composed of **sets**. Reified sets are called **elements**. Any other set is a **non-reified set**.

A set's status as an element is a matter of perspective.

## Classes and singulars

Sets can be instantiated. An instance that can also be instantiated is a **class**, and if they're an instance of a class, they're a **subclass**. An instance that can't be instantiated is a **singular**.

### Elements
An **element** is a set composed by:

- **Content**, a set of data.
	- e.g. the content of an article, a picture, an encylopedia's entry, other elements.
- **Attributes**, a set of metadata.
	- e.g. an URI, an identifier, creation date.

An element whose content is partially or fully composed by other elements is an **composite element**.

### Non-reified sets
**Non-reified sets** are divided into three main classes:

- **Links**, unordered n-tuples whose function is to emphasize some sort of connection between elements.
- **Sequences**, posets whose function is to emphasize some sort of hierarchy between elements.
- **Discourses**, categories whose function is to emphasize some sort of meaning about a set and its elements for gardeners and neighbors.

### Links

**Links** are classified according to their sizes, their functions, and the kinds of elements they can contain:

- **Wikilinks**, n-ary relations whose function is to signal non-specific connections between elements.
- **Transclusions**, intersections whose function is to make elements exist simultaneously in two or more sets.
- **External links**, n-ary relations whose function is to signal non-specific connections between regular elements and elements that represent data outside an environment.

### Sequences

**Sequences** are classified according to their sizes, their topologies, their functions, and the kinds of elements they can contain:

- **Folgezettel**, n-tuples whose function is to signal non-specific continuities/hierarchies between elements.
- **Indexes**, n-tuples whose function is to signal hierarchies between composite elements.
	- e.g. Wikipedia's categories.

### Discourses

**Discourses** are classified according to their sizes, their topologies, the meanings they convey, and the kinds of elements they can contain:

- **Tags**, sets whose function is to convey that its elements are non-specifically related to something.
	- e.g. #hashtags.
- **Schemas**, structures whose function is to assign meaning to sets and elements through a modeling language.
	- e.g. entity-relationship models, ologs, database schemas.

### Handbooks

**Handbooks** are all workflows utilized by gardeners to build and maintain an environment.
- i.e. how are titles capitalized, what backend should be used to visually represent wikilinks between elements, formatting rules for content, controlled vocabularies, etc.

### Default subclasses

Similar Metas may require similar subclasses. The canonical Meta offers **default subclasses** that may be freely used or ignored by other Metas.

#### Elements
- **Concepts**, whose content pertains to describing an object existing outside a garden.
	- e.g. Wikipedia's entries.
- **Propositions**, whose content pertains to a statement and its justification.
	- e.g. Andy Matuschak's note titles, aphorisms, Argdown.
- **Comments**, whose content pertains to a specific resource existing outside a garden.
	- e.g. Marginalia, reading notes, a movie review.
- **Scratchpads**, whose content is purposefully unorganized.
	- e.g. A daily note.
- **Productions**, whose content is not organized according to the Meta.
	- e.g. A poem, an essay, a draft for a paper one wishes to publish.
- **Catalogs**, whose content is composed of references to resources.
	- e.g. A library catalog, a Zotero library.
- **Projects**, whose content is composed of plans, goals, tasks, and other similar things.
	- e.g. Research project, chore list, GTD.
- **Documentation**, whose content describes handbooks and Metas.
	- e.g. You're reading a Documentation right now. Wikipedia's Information pages are also a good example of this.

##### "Concept" default handbook
```markdown
A Concept should have the following Content:
- A definition of the object being described, readable by both humans and machines.
- A series of descriptions about the object.
	- Descriptions can be divided into sections.
		- Sections should be ordered alphabetically.
		- For public gardens, it's good to follow well-known conventions for naming sections. Wikipedia's ones are good ones.
```

##### "Proposition" default handbook
```markdown
A Proposition should have the following Content:
- A thesis.
- A series of arguments.
```

##### "Comments" default handbook
```markdown
Comments should have the following Content:
- Annotations that are structured according to the referenced resource's original structure.
- Annotations that follow their own structure.
```

##### "Scratchpad" default handbook

```markdown
A Scratchpad's Content is fully arbitrary.
```

##### "Production" default handbook

```markdown
A Production's Content is fully arbitrary.
```

##### "Catalog" default handbook

```markdown
A Catalog should have the following Content:
- A set of metadata about a resource.
- If feasible on the garden's medium, the resource itself, embedded or linked to.```

##### "Project" default handbook

```markdown
A Project should have the following Content:
- A definition of the project.
- Arbitrary content pertaining to the project.```

##### "Documentation" default handbook

```markdown
A Documentation should have the following Content:
- A Meta/handbook definition.
- Arbitrary content pertaining to the Meta/handbook.```